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Systems and Methods for Providing Autonomous Security 

CROSS REFERENCE TO RELATED APPLICATIONS 

The application claims priority from the U.S. provisional application entitled 

"Secure Autonomous System and Method for the Internet Protocol" filed on October 

HI* 

15, 2002, with serial number 6O/08#,8O2, which is herein incorporated by reference. 

FIELD OF THE INVENTION 

This invention relates to secure computer networking systems in general and 
in particular to securing autonomous systems that use the Internet Protocol. 



BACKGROUND 

Security systems and secure communication channels are well known for 
15 providing the underpinnings of providing trusted communications among individuals 
and organizations. Having secure communications between parties is desirable for 
financial transactions and confidential communications. 

The emergence of the Internet Protocol version 4 (IPv4) as the universal 
datagram routing protocol has provided a common computer networking protocol 
20 that enables the world's computers to communicate with one another seamlessly 
without regard to geography. As the world's society has come to depend on IPv4 
for commerce it has become increasingly evident that it needs to be secure, 
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especially with the increased use of subnets using portions of the radio spectrum to 
transmit and receive network packets. 

Traditionally, security systems and methods typically either encapsulate IPv4 
within a lower layer security protocol or they use IPv4 to provide routing for a higher 
layer secure networking protocol. 

It would be desirable to have a security system and methods to provide 
secure communications natively within a common routing protocol such as IPv4. 



Patent 

Atty Docket No. ALTEN-00201 



SUMMARY 

Systems and methods for providing autonomous security are configured to 
modify an original header associated with an original data packet wherein key 
5 information is added; encrypt original data associated with the original data packet 
in response to the key information; and form an encrypted data packet including the 
modified header and the encrypted data, wherein the encrypted data packet is a 
same size as the original data packet. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 depicts a diagram illustrating a data flow between a sender, a 
receiver and server according to the invention. 
5 Figure 2 depicts a diagram illustrating a data flow between a sender, a 

receiver and server according to the invention. 

Figure 3 depicts a diagram illustrating the Key or Seed Data Structure 
according to the invention. 

Figure 4 depicts a diagram illustrating unit sizes according to the invention. 
10 Figure 5 depicts a diagram illustrating random Source Pads according to the 

invention. 

Figure 6 depicts a diagram illustrating Mixing Keys according to the invention. 
Figure 7 depicts a diagram illustrating Working Keys according to the 
invention. 

15 Figure 8 depicts a flow diagram illustrating a process of random nested 

shuffling according the invention. 

Figure 9 depicts a diagram illustrating a random nested shuffle of a number 
sequence according to the invention. 

Figure 10 depicts a diagram illustrating an Internet Protocol packet header 
20 with modified fields according to the invention. 

Figure 1 1 depicts a flow diagram illustrating a process of encrypting the data 
payload of outgoing Internet Protocol packets. 
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Figure 12 depicts a flow diagram illustrating a process of decrypting the data 
payload of incoming Internet Protocol packets. 

Figure 13 depicts a diagram illustrating encryption of a series of Internet 
Protocol packets according to the invention. 
5 Figure 14 depicts a diagram illustrating decryption of a series of Internet 

Protocol packets according to the invention. 

Figure 1 5 depicts a flow diagram illustrating a half of the first part of the key 
generation according to the invention. 

Figure 16 depicts a flow diagram illustrating another half of the first part of the 
10 key generation according to the invention. 

Figure 17 depicts a flow diagram illustrating the second and final part of the 
key generation, and encryption or decryption of an Internet Packet data payload, 
according to the invention. 

Figure 18 depicts a flow diagram illustrating a nested shuffle of a source pad. 
15 Figure 19 depicts a flow diagram illustrating a rotation and simple shuffle of a 

working pad. 

Figure 20 depicts a flow diagram illustrating a process of setting up the 
sender computer and the receiver computer. 
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DETAILED DESCRIPTION 

Specific reference is made in detail to the embodiments of the invention, 
examples of which are illustrated in the accompanying drawings and following 

5 descriptions. While the invention is described in conjunction with the embodiments, 
it will be understood that the embodiments are not intended to limit the scope of the 
invention. The various embodiments are intended to illustrate the invention in 
different applications. Further, specific details are set forth in the embodiments for 
exemplary purposes and are not intended to limit the scope of the invention. In 

10 other instances, well-known methods, procedures, and components have not been 
described in detail as not to unnecessarily obscure aspects of the invention. 

In the following descriptions, the following descriptive names will be used: 
Key, Seed, Vector, Pad, Value, Card, Pack, Case, Initialization Vector (IV), random 
number generator (RNG), and pseudo random number generator (PRNG). A Key, 

15 Pad, and Value are populated with random bits from the PRNG. A random factorial 
permutation of a sequence of bytes or numbers will be referred to as a Shuffle. An 
AES Key or an AES IV is a single 16 byte random value. In the following 
descriptions, the following acronyms for the Internet Protocol version 4 (Internet 
Standard RFC 791) will be used: IP and IPv4. 

20 Referring to Figure 1 , a system (100) illustrates a secure autonomous system 

for providing secure communications through the Internet Protocol. The system 
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(100) consists of several interoperating software components and secured computer 
networking protocols. 

In some embodiments, there is a central Key and Pad Server (102), also 
known as a Key Distribution Center (KDC), that supplies all the cryptographic 

5 materials necessary used by two communicating computers, a sender computer 
(104) and a receiver computer (106), that are sending and receiving secure IP 
packets (108). In some embodiments, the sender computer (104) and the receiver 
computer (106) communicate via network such as the Internet. 

In some embodiments, the sender computer (104) and the receiver computer 

10 (106) maintain key synchronization with separate Key Management (KM) computer 
networking packets (110). These KM packets are configured to utilize either IP or 
UDP packets as transport. In some instances, both the sender computer (104) and 
the receiver computer (106) request and receive cryptographic key and pad 
materials from the KDC (102) using a secure, mutually authenticated 

15 communications channel (112), called the Privacy Access Line (PAL). 

In some embodiments, the sender computer (104) contains the following 
software components; a Layer-2 Driver (1 14) that communicates with the Network 
Interface Card (NIC) (130), an encryption intermediate driver (116), a Key 
Management (KM) Service (118), a TCP/IP protocol stack (120) and a sender 

20 application (122). 

In some embodiments, the sender application (122) initiates sending clear 
data to the TCP/IP Stack (120). In this embodiment, the TCP/IP stack (1 20) 
formulates a standard IP packet and sends it to the encryption intermediate driver 
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(1 1 6). This driver (1 1 6) communicates with the KM Service (1 1 8) to get any keys 
and IV's it needs to encrypt IP packet data payloads. In some embodiments, the 
KM Service (118) uses either UDP or IP packets to send and receive PAL (1 12) 
packets from the KDC Server (102). The Sender's KM Service (118) uses either 
5 UDP or IP packets to send KM Packets (1 1 0) to the Receiver's KM Service (1 19) to 
notify it that a series of encrypted IP packets will soon be sent to it and that it will 
need to get the appropriate encryption materials. Using a Key and an IV the 
encryption intermediate driver (116) sends an IP packet with an encrypted payload 
and a slightly modified header (with a recomputed check sum) to the Layer-2 Driver 
io (1 14) that in turn makes the NIC (130) transmit the encrypted packet onto the 

communications channel connected to the NIC (132). The slightly modified header 
is shown in more detail in Figure 10. 

In some embodiments, the channel includes any standard IP subnet, like 
Ethernet, Wi-Fi, ATM, etc. In other embodiments, the sender computer (104) and 
15 receiver computer (1 06) can be on the same subnet or on different subnets 
separated by one or more IP routers. 

In some embodiments, the receiver computer (106) then receives the IP 
packets with encrypted data payloads with the NIC (132). The Layer-2 Driver (1 1 5) 
then takes the IP packets from the NIC (132) and sends the IP packets to the 
20 decryption intermediate driver (1 1 7). This driver (1 1 7) communicates with it's 
corresponding KM Service (119) to get any keys and IV's it needs to decrypt IP 
packet payloads. The KM Service (119) uses either UDP or IP packets to send and 
receive PAL (112) packets from the KDC Server (102). In some embodiments, the 
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receiver computer (106) sends acknowledgment packets to the Sender's KM 
Service (118) using KM Packets (110). 

In some embodiments, IP packets with encrypted data payloads may arrive at 
the receiver computer (1 06) out of order and some payloads can be missing. In 

5 some embodiments, the incoming IP packets have their payloads decrypted and the 
IP packet with clear data payloads is sent to the TCP/IP Stack (121 ) that in turn 
transmits the data to the application (123) for processing. 

Referring to Figure 2, the system 100 benefits from access to a reliable, 
moderately fast network for key and pad material distribution. In one embodiment, a 

10 10 Mbps Ethernet LAN is utilized for back channel communications with a central 
Key and Pad Server (202), which contains a RNG and a PRNG. In one 
embodiment, the AES cipher itself will support over 100 Mbps encrypted throughput 
(208) on an ordinary computer's communication interface, typically either 100 Mbps 
or 1 Gbps Ethernet, between the two computers, a sender computer (204) and a 

15 receiver computer (206). In one embodiment, each of these computers shares the 
identical sets of working keys (216), rotation values (218), mixing keys (212), and 
source pads (210), a copy of the key and IV generation algorithm (220), and a copy 
of the AES cipher either in software or hardware. The source pads (210) are 
periodically refreshed on both computers to maintain the maximum level of security. 

20 To extend the life (i.e. keep them secret longer) of the source pads (210), while they 
are on both computers, the server will send out Mixing Keys (212) as needed. More 
frequently, Rotation Values (218) and Working Keys (216) are sent out to each 
machine to regenerate the actual randomly created pad used to derive AES keys 

-9- 



Patent 

Atty Docket No. ALTEN-00201 

and IV's that are used to encrypt the outgoing IP packet's clear data payload or 
decrypt the incoming IP packet's cipher data payload (208). Note that for purposes 
of this document all communications with the Key & Pad Server are considered 
secure, i.e. cryptographically mutually authenticated and private. This could also be 
achieved by having a separate physically secure 10 Mbps LAN dedicated to only 
distributing Keys, Values and Pads from the Server. 

Referring to Figure 3, the random control sequence of unique numbers are 
shown as a key (302). In one embodiment, the key (302) is generated from a 
PRNG. In some embodiments, the key (302) come in sequences 32 unique 
numbers randomly shuffled only from the range of values 0 to 31 . In this 
embodiment, the number of active bits per number is 5. 

Referring to Figure 4, when large sequences of numbers are randomly 
shuffled, they are broken up into certain sizes in one embodiment. The smallest 
size is called a card (402). A card is 1 byte in size. The next larger size is a pack 
(404), which consists of 32 cards. The next larger size is a case (406), which 
consists of 32 packs. The largest size is the large sequence of numbers to be 
shuffled, called a pad (408), which consists of 32 cases. 
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Referring to Figure 5, all keys and IV materials used to encrypt or decrypt IP 
packet data payloads are typically derived from four (4) random source pads (502). 
Each Source Pad (504, 506, 508, 510) consists of 262,144 random bytes that was 
generated by the PRNG on the KDC server. The total size is 1 Megabyte of random 
5 seed material. 

Referring to Figure 6, the first stage of creating keys and IV materials used to 
encrypt or decrypt IP packet data payloads is controlled by mixing keys (602) from 
the KDC server. There are twelve (12) mixing keys (604, 606, 608, 610, 612, 614, 
616, 618, 620, 622, 624, 626). Each mixing key consists of a randomly mixed set of 

io unique numbers from 0 to 31 , one per byte, a total of 32 bytes each. Mixing keys 
(604, 610, 616, 622) are used for Level 1 mixing (L1) of each Source Pad. Mixing 
keys (606, 612, 618, 624) are used for Level 2 mixing (L2) of each Source Pad. 
Mixing keys (608, 614, 620, 626) are used for Level 3 mixing (L3) of each source 
pad. The total size is 384 bytes. 

15 Referring to Figure 7, the second stage of creating keys and IV materials 

used to encrypt or decrypt IP packet data payloads is controlled by a set of working 
keys and rotation values from the KDC server. The are two (2) rotation values (704, 
706), 4 bytes each, and two (2) working keys, 32 bytes each. Each rotation value is 
a random number generated by the KDC's PRNG. Each working key consists of a 

20 randomly mixed set of unique numbers from 0 to 31 , one per byte. These will all 
collectively be referred to as the working keys (702). Total size is 72 bytes. 
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The keys and IV materials as described in Figures 5, 6, and 7 are utilized to 

illustrate a specific, particular embodiment. Other embodiments can be utilized 

without departing from the spirit of the invention. 

Referring to Figure 8, a nested shuffling process is shown by the flow 

5 diagram. At block 802, the 3 mixing keys are received. The 3 mixing keys include 
case keys, pack keys, and card keys. At block 804, a shuffling function is performed 
on each case utilizing a case key for each case, this is a Level 1 shuffle (L1). At 
block 806, each of the shuffled cases are divided into multiple packs. At block 808, 
a shuffling function is performed on each pack utilizing a pack key for each pack, 

10 this is a Level 2 shuffle (L2). At block 810, each of the shuffled packs are divided 
into multiple cards. At block 812, a shuffling function is performed on each card 
utilizing a card key for each card, this is a Level 3 shuffle (L3). 

Referring to Figure 9, a nested shuffling of a sequence of cards proceeds as 
follows. A sequence of cards (902) divided into cases (904), which are then shuffled 

15 according to a case key (916), resulting in randomly permuted sequence of cases 
(906). A case key is also called a Level 1 Key (L1). Then in turn, these shuffled 
cases (906) are subdivided into packs (908), each case being partitioned identically, 
which are then shuffled according to a pack key (918) that is applied once per case 
to each set of packs contained therein, resulting in identically randomly permuted 

20 sequence of packs per case (910). A pack key is also called a Level 2 Key (L2). 
Then in turn, these shuffled packs (910) are subdivided into cards (912), each pack 
being partitioned identically, which are then shuffled according to a card key (920) 
that is applied once per pack to each set of cases contained therein, resulting in 
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identically randomly permuted sequence of cards per pack (914). A card key is also 
called a Level 3 Key (L3). 

Figure 10 reveals a standard IP packet header that has been modified (1002) 
to support the encryption of the IP packet data payload that follows it. Two fields of 

5 the IP header, the fragment identification and the fragment offset have been 
replaced by three fields, the mixing key refresh ratio value or ratio 1 (1006), the 
working key refresh ratio value or ratio 2 (1008) and the offset for selecting key and 
IV values (1004) from a final pad. Optionally, the first bit of the standard flags field 
(1 01 2) is set to 1 to indicate an encrypted IP packet, or the last bit of the type of 

io service field (1014) may be set to 1 to indicate an encrypted IP packet. In some 
embodiments, these bits are unused by Internet standards. These bits are not 
required to be set for successful encryption and subsequent decryption of the IP 
data payload. After all the fields have been written, the header checksum field 
(1010) will need to be recomputed before the IP packet with encrypted data payload 

15 is transmitted. The flow diagram as depicted in Figure 6 is merely one embodiment 
of the invention. 

In use, the modified header (1002) allows an unencrypted data packet to be 
encrypted without changing the overall size of the encrypted data packet compared 
with the unencrypted data packet. By replacing the fragmentation identification and 
20 the fragment offset with the ratio 1 value, the ratio 2 value, and the IV values, the 
overall size of the data packet remains the same. 

The flow diagrams in Figures 11, 12, and 1 5-20, illustrate one particular use 
of the invention based on a specific application. In other embodiments, the 
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invention may be utilized with other applications. The blocks within the flow 
diagrams can be performed in a different sequence without departing from the spirit 
of the invention. Further, blocks can be deleted, added, or combined without 
departing from the spirit of the invention. 

5 Referring to Figure 1 1 , an exemplary process to encrypt and send IP packets 

is shown by the flow diagram. When the sender's application sends data to the 
receiver's application it causes an IP packet to be created by the sender's TCP/IP 
stack and readied for transmission. When this occurs the sender's KM Service 
requests key and pad materials from the KDC using a PAL request packet. In many 

10 embodiments, PAL protocol packets are secured using any number of well-known 
techniques. It can be a modified Kerberos protocol, with extensions to allow the 
receiver to communicate with the KDC. Or it can be like the TriStrata PAL protocol. 

In block 1 102, the KDC provides a session identifier both in the clear and 
encrypted with a key only the KDC knows inside a PAL response packet. In some 

15 embodiments, this session identifier will be used by the KDC to keep track what 
keys and pads have been issued for any given set of encrypted packets flowing 
between the sender and receiver computers. In some embodiments, the PAL 
response packets are utilized to transmit the keys securely to the sender computer 
and the receiver computer. 

20 In block 1 104, the sender's KM Service transmits the encrypted session 

identifier to the receiver's KM Service using a special KM packet over UDP or IP, 
this is also known as the session setup packet. In some embodiments, the 
encryption of the session identifier can be done in any known appropriate method 
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for correctly securing a small piece of important data. For example, in one instance, 
the session identifier can be encrypted with the AES cipher using a CBC mode with 
128-bit key. Additionally, a SHA-2 one-way hash with a 256-bit digest could be 
computed over the encrypted Session Identifier, encrypted and attached to it. 

In block 1 106, the sender's KM Service requests source pads from the KDC. 

In block 1 108, a local ratio 1 counter is set to zero. In block 1110, the mixing 
keys are requested from the KDC. In block 1 1 12, a local ratio 2 counter is set to 
zero. In block 1114, the working keys and rotation values are requested from the 
KDC. 

In block 1116, the encryption intermediate driver creates the 16 Kbyte 
Working Pad. In block 1118, the local offset value for selecting a AES Key and an 
IV from the final pad is set to zero. In block 1 120, the IP packet with a clear data 
payload is delivered by the TCP/IP stack to the encryption intermediate driver. 

In block 1 122, using the offset value, the key and IV are extracted from the 
final pad. For example, in one instance, the encryption of an IP packet's data 
payload utilizes a 16 byte AES key and a 16 byte IV value, for a total of 32 bytes. 
There are 512 unique pairs of AES key and IV values that can be extracted from a 
16 Kilobyte Final Pad. In some embodiments, each unique pair is associated with 
an offset value from 0 to 51 1 . Each offset value must be at least 9 bits in size. 

In block 1 124, the encryption intermediate driver then encrypts the IP 
packet's data payload with the extracted AES key and IV values. For example, in 
one instance, the encryption of the payload could use the AES key and IV with a 
NIST approved AES counter mode (CTR) to operate as a stream cipher. This 
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allows each byte of the IP packet's data payload to be encrypted without requiring 
any pad bytes to make it aligned with a block size of 16 bytes. 

In block 1 126, the offset value, 9 bits, is written into the unused fragmentation 
field of the IP packet. In block 1128, the ratio 1 and ratio 2 values, 8 bits each, are 
5 written into the fragmentation identification field. In one embodiment, the ratio 1 and 
ratio 2 values are replaced by adding an extra bit in the offset value to prevent the 
rollover of it from 51 1 to 0 without detection. In one instance, the offset value is 
larger, and consumes all the available bits in the standard IP fragment identifier and 
fragment offset fields. 

10 In block 1 1 30, after modifying the IP header fields, the header checksum is 

recomputed. In block 1 132, the header checksum is written into the IP header 
again. 

In block 1 134, the encryption intermediate driver gives the IP packet with the 
modified header and encrypted data payload to the Layer-2 Driver. In block 1 134, 
15 the IP packet with the modified header and encrypted data payload is given to the 
NIC that then transmits it to the receiver computer. 

In block 1 1 36, a value is added to the offset value. In block 1 1 38, if the offset 
value is less than 512 then return to the block 1 120. In block 1 140, a value is added 
to the ratio 2 value. In block 1 142, if the ratio 2 value is less than 512 then return to 
20 the block 1114. In block 1 144, a value is added to the ratio 1 value. In block 1 146, 
if the ratio 1 value is less than 512 then return to the block 1 106. 

Referring to Figure 12, an exemplary to receive and decrypt encrypted IP 
packets is shown by the flow diagram. In block 1202, the receiver KM Service 
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receives an encrypted session identifier from the sender from a special KM packet 
over UDP or IP, the Setup Packet. In block 1204, the encrypted session identifier is 
sent to the KDC Server using a PAL request packet. In block 1206, the KDC 
decrypts the encrypted session identifier and responds with the session identifier 

5 inside a PAL response packet. 

In block 1208. the receiver's KM Service requests and receives source pads 
from the KDC. In block 1210, a local ratio 1 counter is set to zero. In block 1212, 
the mixing keys are requested from the KDC. In block 1214, a local Ratio 2 counter 
is set to zero. In block 1216, the working keys and rotation values are requested 

10 from the KDC. In block 1218, either the KDC or the encryption intermediate driver 
creates the 16 Kbyte working pad. In block 1220, the local offset value for selecting 
a key value and an IV value from the final pad is set to zero. 

In block 1222, an encrypted IP packet arrives from the Layer-2 driver and is 
sent to the encrypted intermediate driver. In block 1224, it is determined if the ratio 

15 1 and ratio 2 in the IP packet header match the local ratio 1 and ratio 2. If there is 
not a match, the packet is dropped and return back to the block 1222. If there is a 
match, extract the 9 bit offset value from the IP packet's header in block 1226. 

In block 1228, using the offset value, the key and IV are extracted from the 
final pad. In block 1230, the decryption intermediate driver then decrypts the IP 

20 packet's data payload with the extracted AES key and IV values. In block 1232, the 
IP packet with a clear data payload is delivered to the local TCP/IP Stack. In some 
embodiments, the ratio 1 , ratio 2 and offset values can be optionally cleared from 
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the IP packet header, and the header checksum can be recomputed prior to 
delivering the IP packet to the TCP/IP Stack. 

In block 1234, a value is added to the offset value. In block 1236, if the offset 
value is less than 512, then return back to the block 1222. In block 1238, a value is 
5 added to the ratio 2 value. In block 1240, if the ratio 2 value is less than 512, then 
return back to the block 1240. In block 1242, a value is added to the ratio 1 value. 
In block 1244, if the ratio 2 value is less than 512, then return back to the block 
1206. 

In some embodiments, the use of the ratio 1 value and the ratio 2 value for a 
10 given packet indicates which source pad is utilized in encrypting the packet. In 

some instances, the ratio 1 value and the ratio 2 value also assist in determining the 
order of the packets once multiple packets arrive at the receiver computer. For 
example, the packets arrive out of order and the ratio values are utilized to 
determine the correct order of the packets. 
15 In some embodiments, the offset value is utilized to indicate a location within 

the source pad that is identified by the ratio 1 value and the ratio 2 value. In some 
instances, the offset value is utilized to assist in determining the order of the packets 
once multiple packets arrive at the receiver computer. In this example, the offset 
value provides additional ordering assistance when the ratio 1 value and the ratio 2 
20 value repeats. 

Referring to Figure 13, for encryption the cipher machinery (1326) takes as 
input two working pads, derived from the four source pads (1306, 1308, 1310, 
1312), two working keys (1332), two rotation values (1334) , and the 512 IP packets 

-18- 



Patent 

Atty Docket No. ALTEN-00201 

(1328). The two working pads each comes from one of the two nested shuffle 
machineries (1302,1304). One machinery (1302) takes as input two source pads A 
and B (1306, 1308), and two sets of three mixing keys (1316, 1318). The other 
machinery (1304) takes as input two source pads C and D (1310, 1312), and two 

5 sets of three mixing keys (1 322, 1 324). The number of IP packets with clear text 
data (1328) cannot exceed 512 packets, before requiring a new set of Working Keys 
and rotation values. The number of IP packets with clear text data cannot exceed 
131 ,072 packets, before requiring a new set of mixing keys. The number of IP 
packets with clear text data cannot exceed 33,554,432 packets, before requiring a 

io new set of source pads. Every IP packet with clear text data is transformed out into 
a corresponding IP packet with cipher text data (1330). 

Referring to Figure 14, decryption is identical to encryption, except that now 
the cipher machinery (1426) takes as input two working pads, derived from the four 
source Pads (1406, 1408, 1410, 1412), two working keys (1432), two rotation values 

15 (1434) , and the cipher text data (1428). The two working pads each comes from 
one of the two nested shuffle machineries (1402,1404). One machinery (1402) takes 
as input two source pads A and B (1406, 1408), and two sets of three Mixing Keys 
(1416, 1418). The other machinery (1404) takes as input two source pads C and D 
(1410, 1412), two substitution keys C and D (1420), and two sets of three Mixing 

20 Keys (1422, 1424). The number of IP packets with cipher text data (1428) cannot 
exceed 512 packets, before requiring a new set of working keys and rotation 
Values. Note that within each group of 512 packets, packets can be lost or arrive 
out of order. Packets delayed by network latency that arrive after a new set of 
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working keys and rotation values have been used, cannot be decrypted and must be 
thrown away. The number of IP packets with cipher text data cannot exceed 
131 ,072 packets, before requiring a new set of mixing keys. The number of IP 
packets with cipher text data cannot exceed 33,554,432 packets, before requiring a 

5 new set of source pads. Every IP packet with cipher text data is transformed out 
into a corresponding IP packet with clear text data (1430). 

Figure 15 reveals an internal view of a half of an initial phase of the cipher 
machinery. The source pad A of 32 kilobytes (1502) is nested shuffled (1510) with 
the three mixing keys A (1506) resulting in a shuffled source pad A of 32 kilobytes 

10 (1514). The source pad B of 32 kilobytes (1504) is nested shuffled (1512) with the 
three mixing keys B (1508) resulting in a shuffled source pad B of 32 kilobytes 
(1516). XOR the two resulting pads together (1526), byte-by-byte, and the result is 
a 32-kilobyte working pad A (1528). 

Figure 16 reveals an internal view of another half of the initial phase of the 

15 cipher machinery. The source pad C of 32 kilobytes (1602) is nested shuffled (1610) 
with the three mixing keys C (1606) resulting in a Shuffled Source Pad C of 32 
kilobytes (1614). The source pad D of 32 kilobytes (1604) is nested shuffled (1612) 
with the three mixing keys D (1608) resulting in a shuffled source pad D of 32 
megabytes (1616). XOR the two resulting pads together (1626), byte-by-byte, and 

20 the result is a 32-kilobyte Working Pad B (1 628). 

Figure 17 reveals an internal view of a final phase of the cipher machinery. 
The working pad A (1702) is rotated and then simple shuffled (1706), using a 
working key A (1710) and a rotation value A (1714), then extract half of each of the 
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cards (1718), and the result is a 16-kilobyte temporary pad A (1722). The working 
pad B (1704) is rotated and then simple shuffled (1708), using a working key B 
(1712) and a rotation value B (1716), then extract half of each of the cards (1720), 
and the result is a 16-kilobyte temporary pad B (1726). XOR the two resulting 

5 temporary pads (1722, 1726) together (1724), byte-by-byte, and the result is a 16- 
kilobyte final pad (1728). This final pad can then be used with a 9-bit offset value 
(1729), which is incremented by one for each IP packet, to extract a unique 16-byte 
AES key and a unique 16-byte IV from each 32-byte position within the final pad. 
Using the key and IV as inputs into an AES cipher in counter mode (1731) results in 

10 a PRNG stream of bytes to XOR (1 730) with IP packet clear text data payload 

(1732), byte by byte, resulting in IP packet cipher text data payload (1734). Or it can 
be used with a 9-bit Offset Value (1735) extracted from IP packet header (2039) to 
extract the AES key and IV from a 32-byte position within the Final Pad. Using the 
key and IV as inputs into an AES cipher in Counter Mode (1737) results in a PRNG 

15 stream of bytes to XOR (1 736) with IP packet cipher text data payload (1 738), byte 
by byte, resulting in IP packet clear text data payload (1740). 

Referring to Figure 18, the operation to nested shuffle a source pad A or B or 
C or D of 32 kilobytes each utilizes three mixing keys; a case key (1802), a pack key 
(1804) and a card key (1806), each having 32 unique 5-bit random numbers. The 

20 source pad is partitioned into 32 cases (1808). The cases (1808) are all shuffled 
together randomly (1810), using the case key (1802) to determine the shuffle 
pattern, and results in a random sequence of cases (1812). Each case is further 
partitioned into 32 Packs (1814). The packs (1814) within each case are shuffled 
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together randomly (1816), using the pack key (1804) to determine the shuffle 
pattern, and results in a random sequence of packs (1818), identically shuffled per 
case. Each pack within each case is further partitioned into 32 cards (1820) of one 
byte each. The cards (1820) within each pack are shuffled together randomly 

5 (1822), using the card key (1806) to determine the shuffle pattern, and results in a 
random sequence of cards (1824), identically shuffled per pack. These three levels 
of shuffling, Level 1 (L1 ), Level 2 (L2) and Level 3 (L3), result in a randomly shuffled 
source pad, which has (2 32 ) 3 or 2 96 random permutations, i.e. entropy of 96 bits. 

Referring to Figure 19, this illustrates the core operation of generating the key 

10 and IV for each IP packet. First, a working pad of 32-kilobytes (1906) is randomly 
rotated by 4-byte intervals using the random rotation value (1904). Then, the 
working pad is sub-divided into 1024 packs (1908) of which each is further sub- 
divided into 32 cards (1910) where a card is 1 byte in size. Using the working key 
(1902), the cards are shuffled in the 1 st Pack (1912). This results in 32 randomly 

15 shuffled cards in the first pack (1914). This is repeated from 2 nd to the last pack in 
the working pad. This results in a 32 kilobyte rotated and shuffled working pad 
(1916). Finally we extract the first 16 cards of each pack (1918) and assemble them 
into an 16 kilobyte temporary pad (1920). 

This shuffle can be done rapidly since a typical working key and many source 

20 pad packs can be brought in the microprocessor's fastest L1 cache. The working 
key stays in L1 cache, amortizing its load cost from DRAM over all the 1024 packs. 
Further, performance gains can be made by taking advantage of multiple ALU 
pipelines in a CPU to process either larger cards or multiple packs simultaneously. 
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The source pads are considered to be secret, known only to the sender, the 
receiver, and the KDC server. The three levels of four sets of Mixing Keys, along 
with the four Source Pads, which themselves are periodically changed, interact to 
effectively keep the four Source Pads secret for as long as possible. This allows 

5 fast local generation of 33,554,432 keys and IV pairs per set of four source pads. 

Figure 20 illustrates a process for setting up the sender computer and the 
receiver computer for transmitting encrypted data packets. In block 2010, the 
sender computer transmits a request to the KDC for a session identifier. In block 
2020, a clear and encrypted session identifier is sent from the KDC to the sender 

10 computer. In some embodiments, the KDC securely sends this session identifier to 
the sender computer via the PAL. 

In block 2030, the sender computer sends the encrypted session identifier to 
the receiver computer via an unsecured network such as the Internet. In block 
2040, the receiver computer transmits the encrypted session identifier to the KDC. 

15 In block 2050, the KDC transmits a clear session identifier to the receiver computer. 
In Block 2060, the sender computer transmits the session identifier and a request 
for pads and keys to the KDC. In block 2070, the KDC transmits the pads and keys 
to the sender computer. In Block 2080, the receiver computer transmits the session 
identifier and a request for pads and keys to the KDC. In block 2090, the KDC 

20 transmits the pads and keys to the receiver computer. In block 2095, the sender 
computer encrypts data within a packet according to the session identifier and 
sends the encrypted packet to the receiver computer over the unsecure network. 
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In some embodiments, the session identifier allows the sender computer to 
correctly encrypt the data packet and allows the receiver computer to correctly 
decrypt the data packet. In other embodiments, the session identifier also provides 
a convenient avenue to update policy restrictions and provide instructions to the 

5 sender computer and the receiver computer. 

In some embodiments, the keys and IV are distributed to the sender 
computer and the receiver computer from the VDC through the PAL. In some 
instances, the keys and IV are periodically sent to the sender computer and the 
receiver computer. In other instances, the keys and IV are sent to the sender 

10 computer and the receiver computer on an as needed basis. In yet other instances, 
the keys and IV are sent to the sender computer and the receiver computer along 
with the session identifier. 

The systems and methods for providing autonomous security deliver a secure 
and efficient mechanism for transmitting encrypted IP packets between sender and 

15 receiver computers. The systems and methods for providing autonomous security 
function within the size constraints of an unencrypted IP packet and neither 
introduce extra bytes into the encrypted IP packet nor increase the overall size of 
the encrypted IP packet by utilizing the slightly modified header (1002). In addition, 
the systems and methods for providing autonomous security encrypt and decrypt in 

20 such a manner as to minimize the burden on the host computer and to take full 
advantage the performance capabilities of modern microprocessor architectures. 

The foregoing descriptions of specific embodiments of the invention have 
been presented for purposes of illustration and description. They are not intended 

-24- 



Patent 

Atty Docket No. ALTEN-00201 

to be exhaustive or to limit the invention to the precise embodiments disclosed, and 
naturally many modifications and variations are possible in light of the above 
teaching. For example, even though specific embodiments utilize the Ipv4 standard, 
any routing protocol can be utilized with the invention. 

5 The embodiments were chosen and described in order to explain the 

principles of the invention and its practical application, to thereby enable others 
skilled in the art to best utilize the invention and various embodiments with various 
modifications as are suited to the particular use contemplated. It is intended that the 
scope of the invention be defined by the Claims appended hereto and their 

10 equivalents. 
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